The 640 MEG Shareware Studio 2/The 640 Meg Shareware Studio CD-ROM Volume II (Data Express)(1993).ISO/info/vl5_185.zip/VL5-185.TXT

Internet Message Format | 1992-11-20 | 31KB

From lehigh.edu!virus-l Thu Nov 19 23:15:32 1992
Date: Thu, 19 Nov 1992 10:23:44 -0500
Message-Id: <[e-mail]>
Comment: Virus Discussion List
Originator: [e-mail]
Errors-To: [e-mail]
Reply-To: <[e-mail]>
Sender: [e-mail]
Version: 5.5 -- Copyright (c) 1991/92, Anastasios Kotsikonas
From: "Kenneth R. van Wyk" <[e-mail]>
To:   Multiple recipients of list <[e-mail]>
Subject: VIRUS-L Digest V5 #185
Status: R

VIRUS-L Digest   Thursday, 19 Nov 1992    Volume 5 : Issue 185

Today's Topics:

Re: SCAN Ver 97 & Monkey Virus (PC).
Re: Need info on MONKEY virus (PC)
Re: SCAN 95b doesn't find MtE in EXE files (PC)
Re: Dangerous bug in CLEAN 97 (PC)
Re: F-Prot's (v2.05) memory scanning. (PC)
Re: How good is Norton Antivirus? (PC)
Monkey Virus (PC)
Re: How good is Norton Antivirus? (PC)
Re: KEY Press virus & McAfee v97 (PC)
F-PROT question (PC)
Re: VSUM Listing (PC)
Apologies to Padgett, and clarification (PC)
Stoned virus Recovery (PC)
Re: SCANV97 don't work in OS/2 dosbox (OS/2) (PC)
re: CHRISTMA effects (CVP)
Re: CHRISTMA Effects (CVP)
Things that keep me awake at night
Australian anti-virus site
Being forthcoming...
MtE detection tests (part 1/5) (PC)

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc.  (The complete set of posting guidelines is available by
FTP on cert.sei.cmu.edu or upon request.) Please sign submissions with
your real name.  Send contributions to [e-mail].
Information on accessing anti-virus, documentation, and back-issue
archives is distributed periodically on the list.  A FAQ (Frequently
Asked Questions) document and all of the back-issues are available by
anonymous FTP on cert.org (192.88.209.5).  Administrative mail
(comments, suggestions, and so forth) should be sent to me at:
<[e-mail]>.

   Ken van Wyk

----------------------------------------------------------------------

Date:    Tue, 17 Nov 92 03:43:45 +0000
From:    [e-mail] (John Mechalas)
Subject: Re: SCAN Ver 97 & Monkey Virus (PC).

[e-mail] (Tim Martin; FSO; Soil Sciences) writes:
>But it isn't trivial, so instead you might want to get a copy of
>my KILLMONK program, which does that and more for you.  It uses
>some careful identification strings, checks that the recovered MBR
>is correct, etc.  Also makes scanning and cleaning of floppies
>easy.  And strictly speaking, it doesn't require a clean boot, as
>long as the only virus messing things up at the time is Monkey.
>
>I think KILLMONK may have been posted at some of the ftp sites.
>If you can't find it, or want me to send it (uuencoded) via
>e-mail, drop me a note.  (It's free of course, and worth every
>virtual cent!)

I found killmonk.zip at oak.oakland.edu, so I assume it is at all of
the SIMTEL20 mirrors.  It's in the trojan-pro directory, by the way.
- --
John Mechalas                      | If you think my opinions are Purdue's, then
[e-mail]      |      you vastly overestimate my importance.
Purdue University Computing Center |             Help put a ban on censorship :)
General Consulting                 |                       #include disclaimer.h

------------------------------

Date:    Tue, 17 Nov 92 01:42:46 -0500
From:    [e-mail] (A. Padgett Peterson)
Subject: Re: Need info on MONKEY virus (PC)

>From:    [e-mail] (Tim Martin; FSO; Soil Sciences)

>Third, the Monkey virus specifically (and successfully)
>bypasses Padgett's Disk Secure program.  This virus represents
>a rare case: a very specific attack against a very specific
>disk security system.  Fortunately most scanners will find
>the virus in memory.  Again this stresses the importance of
>having a multi-layer antivirus strategy.

Like I said, no software is proof against a directed attack, *however*
the DOS validator (CHKSEC) in the latest DS will detect the fact that
the proper code is not resident in memory and the Monkey cannot
prevent *that*.

Incidently, it was said that FixMBR cannot remove the Monkey - this is
true however if FixMBR was executed *before* infection and the .DAT
file saved, use of it as directed after booting from floppy will
restore the MBR & table as will the DiskSecure recovery disk.

            Cooly (in Chicago in November ?)

                  Padgett

------------------------------

Date:    Tue, 17 Nov 92 07:32:33 +0000
From:    [e-mail] (McAfee Associates)
Subject: Re: SCAN 95b doesn't find MtE in EXE files (PC)

Hello Vesselin,

you write
[a ">>" means I write]

[...part about SCAN 97 missing representative samples from each set
of your MtE-based viruses deleted for brevity...]

>                           Unless, of course, you mean my previous
>message, in which I stated that SCAN 95b does NOT detect the MtE-based
>viruses in ANY infected EXE files AT ALL, which is also true.

Correct.  SCAN 95-B was released before we had any samples of
MtE-based viruses which infected .EXE files.  Detection was added in
V97 (the V96 release was skipped due to a Trojan horse).

>Regardless which of my messages you meant, they are both true and I
>have facts that prove both of them. If you consider my message about
>those facts to be alarmist, you are free to think so. Try to explain

Okay.

>it to your users. But please, don't object the facts. The facts are

I have been :-).  I don't believe I was objecting to your results.

>that SCAN is still unable to detect reliably ANY of the MtE-based
>viruses. It was my duty to warn its users about this.

[... my comments about MtE-based virus spread deleted...]

>I am not arguing about how widespread the MtE-based viruses are. They
>are not. What I am arguing about is that SCAN 97 is not able to detect
>reliably ANY of them. For a known virus, there is no such thing as
>99.8% detection. You either can detect it, or you cannot. Try

Are you sure?  I can see two opposing schools of thought forming here:
One of "all or nothing" detection (the binary operation school of
thought), and one of "percentages" of detecting (the analog school of
thought)?  Without getting too far off track, here, I believe that
there will be more "percentage" reports in the future, especially as
more complex forms of viral code emerge.

>explaining your users that they should not be alarmed, because SCAN
>misses "only" about one infected file in every 50. Besides, 319 missed
>samples of 15,994 is 98% (not 99.8%), i.e. one missed sample in every
                      ^^^^^^^^^^^^^^^
My mistake.  Sorry about that.

>50.

[...my suggestion for wording of reports deleted...]

>OK, I'll use this wording the next time. But I will not miss to say
>that "SCAN version xx missed X out of Y samples of the Z virus, which
>means that this version of SCAN is NOT able to detect the Z virus
>reliably. I've notified McAfee Associates of the problem and they will
>(hopefully) fix it shortly."

<GRIN>  Beautiful.

>> >an article posted somewhere (maybe even here), which described how
>> >McAfee Associates sponsored a particular set of anti-virus product
>> >evaluations and insisted that only old versions of the scanners of
>> >their main competitors were tested.
>
>> McAfee Associates has sponsored (that is, paid for) anti-virus product
>> testing by a number of independent organizations, using then-available
>> versions of competitors' anti-viral programs.  To do otherwise would be
>> worthless.
>
>More exactly, the article said that McAfee insisted that OLD versions

The article (I wish I knew which one) could have have said that.  It
does not mean that it is true, though.

>of the competitive scanners were used in those tests and that he was
>quoted saying that he wants his competitors to show worse results in
>such tests. To do otherwise might be worthless from the economical

I think its fairly easy to guess that John McAfee would like his programs
to do better then anyone else's in a test.  I'm sure that is hardly
unique, though.

>point of view, but it would be honest from the human point of view...

[...deleted...]
>I hope so. This is one of the reasons for posting my message. Just
>have in mind that the bugs in security-related software (like
>anti-virus programs) are more dangerous. I'll do my best to continue
>reporting them.

If possible, would you mind sending me a copy of any such reports?  (Only
on McAfee Associates software, that is).  Thank you.

Regards,

Aryeh Goretsky
Technical Support

PS:  SCAN V99 should be available about the time you read this.  I'd
     be very interested in hearing how it does--the MtE-based virus
     detector was rewritten.  AG
- --
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
McAfee Associates, Inc.  | Voice [phone] | INTERNET:
3350 Scott Blvd, Bldg 14 | FAX   [phone] | [e-mail]
Santa Clara, California  | BBS   [phone] | CompuServe ID: 76702,1714
95054-3107  USA          | USR HST Courier DS   | or GO MCAFEE
Support for SENTRY/SCAN/NETSCAN/VSHIELD/CLEAN/WSCAN/NETSHIELD/TARGET/CONFIG MGR

------------------------------

Date:    Tue, 17 Nov 92 07:38:39 +0000
From:    [e-mail] (McAfee Associates)
Subject: Re: Dangerous bug in CLEAN 97 (PC)

Hello Vesselin,

you write:
[...message about CLEAN not removing the Michelangelo from 1.2Mb diskettes
deleted for brevity...]
>McAfee Associates has been notified of the bug and they are probably
>already working on the solution. Hopefully, the bug will be fixed in
>the next release of CLEAN.
[...deleted...]

Noted and in the queue of things to be looked into.  A new version of
CLEAN should be ready early next week fixing this, barring any
unforseen problems.

Regards,

Aryeh Goretsky
Technical Support

- --
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
McAfee Associates, Inc.  | Voice [phone] | INTERNET:
3350 Scott Blvd, Bldg 14 | FAX   [phone] | [e-mail]
Santa Clara, California  | BBS   [phone] | CompuServe ID: 76702,1714
95054-3107  USA          | USR HST Courier DS   | or GO MCAFEE
Support for SENTRY/SCAN/NETSCAN/VSHIELD/CLEAN/WSCAN/NETSHIELD/TARGET/CONFIG MGR

------------------------------

Date:    17 Nov 92 08:58:23 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: Re: F-Prot's (v2.05) memory scanning. (PC)

[e-mail] (J.EDWARDS) writes:

>After hours of failing to get Windows to install, the owner suddenly
>announced he thought his computer might be infected.  I ran F-Prot
>straight away and sure enough it announced it had detected 'Stoned' in
>memory.  I booted from my clean floppy and when running F-Prot again
>it claimed the hard-disk was infected with not 'Stoned' but
>'Michaelangelo'.

The reason for this is simple - The memory scan only reports the virus
family, not the exact variant name.  As Michelangelo has been
classified as a member of the "Stoned" family, it reports "Stoned".
When you scan the boot sector, F-PROT identifies the variant - in this
case Michelangelo.

- -frisk

------------------------------

Date:    17 Nov 92 09:02:20 +0000
From:    [e-mail] (Fridrik Skulason)
Subject: Re: How good is Norton Antivirus? (PC)

[e-mail] (007) writes:

>   + The ability to allow the user to add new scan strings, including the use
>     of wildcards.  (F-prot does this w/o wildcards.)

No - you can use wildcards - although it does not allow
variable-length wildcards. A "??" in the pattern stands for a single,
variable byte.

- -frisk

------------------------------

Date:    Tue, 17 Nov 92 08:16:51 -0500
From:    William Webber <[e-mail]>
Subject: Monkey Virus (PC)

Copy of Monkey virus found: UK London (JMP 01D0).

Reguards

        William Webber...

------------------------------

Date:    Tue, 17 Nov 92 15:47:41 +0000
From:    [e-mail]
Subject: Re: How good is Norton Antivirus? (PC)

My norton anti-virus is very old, but it does the job. Although it
keeps moaning about it's age.....oh well......ho...hum

------------------------------

Date:    17 Nov 92 17:08:43 +0000
From:    [e-mail] (Vesselin Bontchev)
Subject: Re: KEY Press virus & McAfee v97 (PC)

[e-mail] (McAfee Associates) writes:

> >point is, however, that SCAN is occasionally not very accurate in determinin
g
> >exactly which virus you have.

> I understand that, believe me.  We will fix any such problems reported
> to us.

Will you? Any such problems? Let's hope... Because, if memory serves
correctly, I am reporting such problems to you since about a year...
Such problems include:

1) Viruses mentioned in VIRLIST.TXT but never reported by SCAN.

2) Viruses reported by SCAN but never mentioned in VIRLIST.TXT.

3) Viruses mentioned under one name in VIRLIST.TXT, but reported under
a slightly different name by SCAN.

4) Viruses described with wrong properties in VIRLIST.TXT.

5) Several (often - completely different) viruses reported with one
and the same name. This is the most dangerous problem, since it causes
misidentification. As a reply of one of my reports about these, I got
a very angry reply from John McAfee himself. The reply was posted from
your account, so you should know about it. It claimed that the viruses
mentioned by me are actually closely related. Those viruses were
Number of the Beast, Compiler.1, and Darth Vader. Anybody who has
bothered to disassemble them knows that they are completely
different... BTW, SCAN 97 still reports all the three of them as "512
[512]"... :-(

Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
Tel.:[phone], Fax: [phone]      Fachbereich Informatik - AGN
< PGP 2.0 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: [e-mail]    D-2000 Hamburg 54, Germany

------------------------------

Date:    Tue, 17 Nov 92 12:21:12 -0500
From:    tuan <[e-mail]>
Subject: F-PROT question (PC)

Virus-lers,

  Can any tell me why "Blem wit" is the program name when I load
virstop.exe?

  Background:
  PS2 node connected to novell netware LAN...Ipx and net5 are loaded
first and then virstop is loaded from the network drive.

  Is this a problem? if no, why does it occur? if yes, what are the
side affects?

  thank you for all your help.
  -tuan nguyen-
   programmer
   pace university

------------------------------

Date:    Tue, 17 Nov 92 18:27:53 +0000
From:    [e-mail] (Gerald Pfeifer (Prak Gusti))
Subject: Re: VSUM Listing (PC)

[e-mail] (Scott Begin) writes:

> [ Some questions about VSUM ]

Yes, it runs an 8088 to 80486, and on Hercules as well as on VGA....
The VSUM-package contains everything you need except DOS....
It is available on most antiviral FTP-Sites (try risc.ua.edu, urvax.urich.edu)

BUT: Some experts (Bontchev, Frisk...) in this group do *not* recommend VSUM.

A while ago I heard that the VTC Hamburg (where Bontchev works) is going
to release a dBase version of there virus catalog. I have not seen it
yet, but if anyone in this group knows, please let us know.....

Please no flaming about this topic!!!!

Gerald

...........................................................................
. Gerald Pfeifer (Jerry)              Technical University Vienna, Austria .
. [e-mail]     Home: Mondweg 64, 1140 Wien, Austria .
...........................................................................
. Sorry, I'm not a native speaker (flames to /dev/null)                    .
...........................................................................

------------------------------

Date:    Tue, 17 Nov 92 12:20:55 -0700
From:    [e-mail] (Tim Martin; FSO; Soil Sciences)
Subject: Apologies to Padgett, and clarification (PC)

Reading over two of my recent posts, about the Monkey virus, I realize
one could get the impression I am critical of Padgett Peterson's
"Fixutils" and "Disk Secure" packages.  Not at all!

I still find Disk Secure to be the best, simplest, and cheapest
software way I know of to protect against MBR infectors.  That's why
the University of Alberta uses it in all its "public access" DOS
computer labs.  And that, unfortunately, is why Monkey was written to
by-pass Disk Secure.  Far from a statement against Disk Secure, this
is a lesson on the limitations of any software-based protection
system: a directed attack, however unlikely, is always a possibility.

Similarly FixMBR demonstates an interesting and straightforward way to
recover from almost all MBR viruses.  But not from Monkey, and
presumably once again for the same reason.  :)

Tim.

 -------------------------------------------------------------
  Tim Martin                   *
  Spatial Information Systems  *  "I really don't see how returning
  University of Alberta        *       the product helps me."
  [e-mail]        *
 -------------------------------------------------------------

------------------------------

Date:    Wed, 18 Nov 92 00:20:07 +0000
From:    [e-mail] (Rahul Ravel)
Subject: Stoned virus Recovery (PC)

Hi all,

About 1 1/12 weeks ago I posted a query on how to get rid of the
Stoned virus on a friend's pc.  Just wanted to say 'Thanks" to all who
e-mailed.

FYI, I used Paul Padgett's FixMBR utility to restore the original boot
record.  No loss of data.  Thanks, Paul!

- -Rahul, [e-mail]

"Only my own opinions here"

------------------------------

Date:    Tue, 17 Nov 92 05:27:09 +0000
From:    [e-mail] (Wey Jing HO)
Subject: Re: SCANV97 don't work in OS/2 dosbox (OS/2) (PC)

[e-mail] (Christer Olsson) writes:

>I'm trying to use scan version 97 in a DOS-box but OS/2 trows out the
>scan with an error message saying that SCAN uses illegal 386
>instructions.

>Version 95 works fine, but not 97.

>The machine is a AST 486/E Premium at 33 Mhz with 10 Mb of memory and
>OS/2 2.01 beta.

It works for me in OS/2 with the OCT'92 CSD applied. The only
complains I get are that certain files are currently being used.

- --
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>Wey Jing Ho    Tel: [phone]   E-mail : [e-mail]<
>Physics Dept., Monash University ( Caulfield Campus ), Melbourne, AUSTRALIA<
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

------------------------------

Date:    Tue, 17 Nov 92 12:29:59 -0500
From:    "David M. Chess" <[e-mail]>
Subject: re: CHRISTMA effects (CVP)

> From:    [e-mail]

>IBM's internal network,
>VNET, was more heavily hit than either EARN or Bitnet, and drastic
>action, in the form of a general system shutdown, was felt to be
>needed to clear up the mess.

This is an urban legend, I'm pretty sure (if you have a good primary
source for the statement, let me know).  I was on vacation when
CHRISTMA hit, but was involved to some extent in the followup
investigations.  As far as I know, VNET was never shut down as a
whole; it was even more a distributed system then than it is now, and
I don't think anyone knew then of a way to shut it all down if they'd
wanted to!  The various systems that were hit responded in various
ways.  Some wrote little demons that went through and purged any
CHRISTMA EXECs that showed up in the spool, some that were lightly hit
did this manually, and some that were very heavily hit no doubt
elected to shut down while dealing with it.  But the story that "IBM's
internal network was completely shutdown" is a myth, as far as I
know...  DC

------------------------------

Date:    Tue, 17 Nov 92 08:38:29 -0500
From:    Bridget Rutty <[e-mail]>
Subject: Re: CHRISTMA Effects (CVP)

The CHRISTMA exec did NOT destroy itself after sending copies.  I
erased several from our users minidisks.  Also, I did not have to
shutdown our system.  I just listed all the reader files in the system
and purged any CHRISTMA exec I found.  But, there weren't many - I
forget exactly how many there were but it was less than a hundred.
Other sites merely drained their RSCS links (software that delivers
mail and files to other computers) while they cleaned up.  There may
have been some sites that found it necessary to shutdown but I have
not heard of any.  What really stopped the explosion of files was the
BITNET sites that installed a trap in RSCS to erase any CHRISTMA file
sent to it.  When installed in a few strategic nodes, this trap is
very effective at stopping this type of trojan horse.  Two more
attempts at distributing CHRISTMA were stopped as well as a couple of
others whose names I forget.  The defense is good enough that most
people aren't aware of the subsequent attacks.  I haven't seen any
attempts to distribute such trojans in a couple years.

Bridget Rutty                                        [e-mail]


------------------------------

Date:    17 Nov 92 02:14:30 +0000
From:    [e-mail] (The Jester)
Subject: Things that keep me awake at night

Silence. That is what I hear on this net.group. I hear silence.  There
is some discussion about a particular program's ability to detect a
virus and then there is the reason I still read this group, new
product announcements. But the one thing I'v never seen is a
discussion of the mechanics of fighting viruses. Is the viral world
satisfied with it's basic tools, scanner, activity/change monitor, and
heuristic analyizers? Is that the end? Are all of the people in the
community doing nothing more than comming up with new scan codes for
whatever virus has shown up this week, trying to understand the ugly
inards of some os so they can tweak their monitors a little better,
and trying to see yet another combination of code that only a virus
would use? Why is there no real discussion on techniques and ideas? Is
this part of the conspiracy of silence that infects the viral
community?

      Just curious,
            Yaron (The Jester) Goland
- --
RSA proved you could patent math, whats next? Fire?
"Sorry, you can't rub those two stones together!
   First is a Patented Process"
      -The Jester

------------------------------

Date:    Tue, 17 Nov 92 05:58:41 +0000
From:    [e-mail] (Robert G. Reid)
Subject: Australian anti-virus site

An small selection of current Anti-Virus software is once again
available for Australian net users (AARNET) at:
         ftp.psychol.utas.edu.au    (131.217.35.98).

Please address any correspondence re this facility to:
         [e-mail]
- --
[e-mail] <Robert Reid>

------------------------------

Date:    Sat, 14 Nov 92 16:16:45 -0500
From:    [e-mail] (Mr. Tarkan Yetiser)
Subject: Being forthcoming...

   Hello Aryeh,

[e-mail] (McAfee Associates) writes:
> Bugs can be fixed.  Bearing in mind that I am, after all, a McAfee
> Associates employee, I believe that McAfee Associates (and myself) have
> been very forthcoming to users about reporting bugs, fixing them, and
> suggesting workarounds while the bugs do get fixed.

   In keeping up with this tradition of open communications with your
users, would you please share with the readers of this newsgroup the
press release from McAfee Assoc., dated May 11, '92 and titled "Dark
Avenger Mutation Engine No Threat to Protected PCs", with the contact
name Mr. McKiernan?  Out of curiosity, is William McKiernan a McAfee
agent or employee?

   If the requested article is not posted here, curious individuals
can contact me by e-mail to get a copy of what I am talking about, and
judge for themselves the nature of the statements made there. I shall
not comment.

[Moderator's note: It is with great trepidation that I am approving
this message.  Gentlemen, before this gets out of hand, I want to
remind you both to keep this discussion civil.  Otherwise, you can
eliminate the middle man by forwarding any follow-ups directly to
/dev/null...  :-\]

Regards,
Tarkan Yetiser
VDS Advanced Research Group
P.O. Box 9393
Baltimore, MD 21228, U.S.A.
[phone]

------------------------------

Date:    02 Nov 92 18:12:38 +0000
From:    [e-mail] (Vesselin Bontchev)
Subject: MtE detection tests (part 1/5) (PC)

Hello, everybody!

Here is the long awaited report about the MtE detection tests that we
performed at VTC-Hamburg.  It is rather longish, so maybe Ken should
consider splitting it into parts.  Normally, I should have put it for
anonymous ftp, instead of publishing it here, but the preliminary
results of the tests raised enough interest and discussions, so I
decided to publish it in a whole in this newsgroup.  Nevertheless, it
- - -is- available for anonymous ftp as

ftp.informatik.uni-hamburg.de:pub/virus/texts/tests/mtetests.zip

[Moderator's note: The complete text of Vesselin's MtE tests are also
available from:
      cert.org:pub/virus-l/docs/mtetests.zip
As I had previously indicated, I have broken Vesselin's tests down
into five parts and will post each seperately.]

Enjoy.  Comments, questions, and suggestions are welcome.

Regards,
Vesselin
- - --
Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
Tel.:[phone], Fax: [phone]      Fachbereich Informatik - AGN
< PGP 2.0 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: [e-mail]    D-2000 Hamburg 54, Germany

=====

[part 1/5]

                         MtE Detection Tests

1. What is the MtE and what is all this fuss about.

MtE stands for "MuTating Engine". This is a library routine, written
mostly by the Bulgarian virus writer known as Dark Avenger.  It comes
as an .OBJ file.  Every virus writer could simply link this routine to
his viruses.  He must also call the routine in a special way and this
will make the virus to which the MtE is linked extremely polymorphic.
That is, each new instance of the virus in each new infected file will
look differently.  This is achieved by encrypting the virus body,
using each time a different key.

The idea is not new - even the old Cascade virus does this.  However,
the virus must eventually execute itself, therefore it must decrypt
itself. Viruses like Cascade always have a small unencrypted part in
the beginning, called "decryptor". It's task is to decrypt the rest of
the virus body.

Because the major part of the virus body is differently encrypted each
time, no scan string can be selected from it - it just looks
differently in each infected file. However, one can pick a scan string
from the decryptor, because it is not encrypted and looks always in
the same way in all files. This is exactly how the scanners handle
viruses like Cascade.

The polymorphic viruses like Phoenix, Tequila, V2P6, etc. take the
self-garbling one step further. They also have an unencrypted
decryptor in the beginning, but the decryptor is not always one and
the same - the virus modifies it from one infection to another. Some
viruses make just simple modifications, so their decryptors can be
detected, using a wildcard scan string.  That is, a scan string that
can contain "don't care" bytes - indicating that the particular value
of that byte is not important.  The more polymorphic the virus, the
more difficult is to scan for it.

Some polymorphic viruses are so sophisticated, that it is not possible
to detect all forms of their decryptors, even if wildcard scan
strings are allowed...  Such viruses are V2P6, V2P6Z, and others.  In
order to detect them, the scanners must use a special, algorithmic
approach, specific to each particular virus.  This is very difficult
and time consuming, since the producer of the scanner must analyze
very carefully the polymorphic engine of each such virus, and figure
out what code it can generate, and write a special "detection engine"
to detect this code.  In general, the ability to detect extremely
polymorphic viruses reflects the quality of the R&D department of the
particular producer of anti-virus software.

The viruses that are using the MtE (we'll call them MtE-based viruses)
are extremely polymorphic. Much more than V2P6Z, for instance. And
there are still many scanners on  the market, that are unable to
detect reliably even this relatively old and simpler virus.
Furthermore, V2P6Z is relatively simple as virus - it is based on the
old Vienna virus and does essentially the same. It is not very
infectious, because it is nonresident and infects only COM files in
the current directory and in the directories listed in the PATH
variable. Since the MtE can be linked to any new virus, nothing
prevents the virus writers from writing extremely sophisticated,
infectious, and destructive viruses, that will be hard to scan for.

Fortunately, the MtE cannot be used to make an already existing virus
polymorphic. The virus has to be re-designed from scratch, in order to
make it MtE-aware. However, nothing prevents a virus writer from
writing a new virus (or modifying the source of an already existing
one) and to make it MtE-aware. Therefore, it is only a question of
time, before such viruses appear and are spread widely. That's why, it
is important that the currently existing scanners are able to detect
the MtE-based viruses reliably.

Currently only a few MtE-based viruses exist, and all of them are
either incredibly stupid, or buggy, or both.  Neither of them
represents a significant threat, and neither of them is able to spread
widely.  However, as explained above, detection of MtE-based viruses
is important, in general, therefore, detection of the currently
existing MtE-based viruses demonstrates an important ability of the
scanners.

Currently, the number of the scanners that claim to be able to detect
the MtE-based viruses is no more than 2-3 times the number of the
already existing MtE-based viruses... As we shall see below, the
number of them that are able to do this reliably, is even smaller.


------------------------------

End of VIRUS-L Digest [Volume 5 Issue 185]
******************************************